Loadstar 128 #31

home *** CD-ROM | disk | FTP | other *** search

/ Loadstar 128 #31 / q31.d81 / t.128 rle < prev next >

Wrap

Text File | 1992-01-01 | 14.6 KB | 376 lines

1 2 8 R L E Program by Bob Markland Text by Bob Markland and Jeff Jones For several months now RLE file compression has been used to cram up to 35% more programs and text onto each issue of LOADSTAR 64. To accomplish this feat, Jeff Jones wrote a RLE -- Run Length Encoding -- utility, published on LS #134. Recently, Fender sent me Jeff's M/L source code along with a request to make it work on the C-128. After some discussion, Fender and I agreed that Jeff's program did everything he wanted it to, just not in 128 mode. So, if you happen to subscribe to both LOADSTAR 64 and LOADSTAR 128 you will find that 128 RLE works much the same as the C-64 version. (I have a real aversion to re-inventing the wheel). It will pay you, though, to become familiar with the following information because BANK selection and differences in syntax are important considerations on the C-128. RLE is probably the most simple form of data compression next to tokenization. It encodes repetitious data in only two bytes instead of up to 128. RLE uses 4 bytes to encode 256 repeating bytes. In the code, the first byte says how many consecutive bytes to expect. The second byte is the actual byte that's being repeated. So 500 consecutive zeroes are coded as 8 bytes instead of 500. We could code up to 255 bytes, but it's more efficient to use only the lower 128 numbers for repeating characters and the higher 127 for non- repeating data. That way we don't have to have terminating flags, which could possibly take up a lot of room if packing a big file. Thus, we have a method by which the same byte that would flag repeating characters can be used to flag an upcoming stream of non-repeating data. Streams of data that don't repeat are preceded by a byte that is 128 plus the number of non-repeating characters. The machine language easily spots literals and then subtracts 128 from the code. RLE works extremely well with fonts and most hi-res graphics. You wouldn't want to use RLE on text unless it was full of consecutive spaces or other repeating characters. When used in conjunction with a screen switcher, RLE also works well with program and game screens because, except for text screens like the one you're reading now, most screens are full of consecutive spaces. Otherwise they'd look too crowded. So most lend themselves to RLE. And even if the screen doesn't pack well, the color memory of a text screen, even if it varies from line to line, is usually laid out in such a way that the 1000 color bytes would pack down to only a few bytes. (See "Jeff's Tutorial on Packing Screens" below). Heavily dithered, "misty" and "busy" graphics, such as the type created by Walt Harned, won't pack as well with RLE as they would with other forms of compression, though they usually pack somewhat. Basically, the more you see solid, unobstructed blocks of pixels or color, the more packable that graphic is. USING 128/RLE ------------- There are three versions of 128/RLE on the disk: FILENAME SYS LOCATION -------------------------- 128/RLE 0C00 3072 128/RLE 1300 4864 128/RLE 1C00 7168 NOTE: The source code to the routine (in EBUD format) is on the disk in the file, "128/rle.s". Load any one of these files into BANK 0, using: BLOAD"128/RLE xxxx",Un,B0,Pnnnn Which version above is the best one for you to use in a program? That depends on the other ML programs or routines that you might want to use. The first two ($0C00 and $1300) can be used as long as you aren't using that area for other ML routines. The code at $1C00 requires that you open up the graphic area ($1C00-$4000) with a GRAPHIC1 command. FENDER'S NOTE: Since I program only in the 80-column mode on 128 computers, and invariably use CONTROL80, my programs always have BASIC moved up to $4000 with a GRAPHIC1 command. This gives me the area from $1C00 to $4000 for storing screens, data, or even machine language routines like 128 REL. In all the examples 128/RLE observes the following conventions. You will note that they closely parallel BASIC 7.0 commands such as BLOAD and BSAVE, with two major exceptions: (1) You MUST follow the SYS command with a colon (:) rather than a comma. (2) Unlike BASIC 7.0 there are no default values. You MUST supply ALL drive (U), bank (B), and address (P) information, as shown in the examples below. SYSADDR[+N]:A,B$,C ADDR[+N]: is the LOAD address of the M/L module plus N if applicable. A, B$ and C are parameters. Parameters followed by $, such as B$, can be supplied in string variables or literals within quotes or a combination of the two, or any algorithm that creates a string. Numeric parameters can be replaced with variables. NO QUOTES!!! You may also use any formula or equation that generates a positive integer. IMPORTANT NOTE: If you choose to use string variables, a combination of string and literal text in quotes, or numeric variables, they MUST be enclosed in parentheses (). PACKING A FILE -------------- SYSADDR+3:FILE$,U1,B1,P1:DEST$,U2,P2 This command will BLOAD a file to a buffer which you specify and pack it, then SAVE the packed file under a new filename on any active drive, with any LOAD address you desire. ADDR+3 is the location of the pack file code. FILE$ is the parameter where you plug in the filename. Since this isn't an archive utility, and the packed files are meant to be used in memory, the file must be small enough to fit into memory. U1 is the device number of the source drive. B1 is the bank where the source file will be loaded. P1 is the area where the file will be examined by 128/RLE. When you pack from disk file to disk file you will no doubt use the "RLE DISK TO DISK" BASIC program included on this disk (and explained later) or your own embellished version, which will probably be very short. So you can select a buffer at any address in BANK 0, following the BASIC program. This can be as low as 8192, which gives you room for a buffer of 223 blocks ($2000-$FEFF). Address 16384+ ($4000+) in BANK 1 is used as the default output buffer. However, you can select any area of BANK 1, if you find a need, by entering: POKESYS+18,page. For example: POKESYS+18,32 lowers the beginning of the buffer to 8192 in BANK 1. If you find BANKing a little confusing, note that a graphic file being examined at 8192 in BANK 0 and the output buffer at 8192 in BANK 1 do not interfere with one another. You can even select a buffer directly under 128/RLE. DEST$ is the filename of your destination file. U2 is the device number of your destination drive. P2 is the desired LOAD address of the packed file. UNPACKING FILES --------------- Files can be unpacked in one of two ways. Packed files can be BLOADED into a buffer by a routine in your program and then unpacked from one location to another or they can be unpacked straight from disk with the following command: SYSADDR:FILE$,Un,Bn,Pn FILE$ is the filename of the packed file. Un is the device number of the drive containing the file you wish to unpack. Bn is the bank number to which the file is to be loaded (usually 1 or 0). Pn is the desired LOAD address of the data. Making this parameter 0 will cause the unpack routine to respect the LOAD address the file was created with. COMPRESS RANGE OF MEMORY ------------------------ SYSADDR+6:B1,P1,P2,B2,P3 Here you can compress any range of memory and stash the compressed data anywhere in RAM. This is useful if you already have data in memory which you want to compress. Locations 253 and 254 or F% will report the end of the output buffer, which you will need to know if you want to BSAVE the data. If F% is a negative number (integer variables only go up to 32768), you can derive the end from PEEK(254)*256+PEEK(253). B1 is the bank where the decompressed data resides. P1 is the beginning address of the decompressed data. P2 is the ending address of the data to be packed PLUS 1 (+1). B2 is the bank where the packed data is to be placed. P3 is the beginning address where the packed data is to be placed. Remember that data in corresponding areas of BANK 0 and BANK 1 will not cause conflicts. DECOMPRESS DATA IN MEMORY ------------------------- SYSADDR+9:B1,P1,B2,P2 Here you can decompress data already in memory and write it to any location in RAM. B1 is the number of the bank containing compressed data. P1 is the address of the compressed data. B2 is the number of the bank where you want the decompressed data to be written. P2 is the address where you want the decompressed data to be written. PACK RANGE OF MEMORY -------------------- SYSADDR+12 This is the same as "Compress Range of Memory," except that you must first POKE the desired values into memory then SYS directly to the M/L without parameters. POKE176,n - Bank containing decompressed data. POKE251,n:POKE252,n - Low byte/high byte for the beginning address of the decompressed data. POKE174,n:POKE175,n - Low byte/high byte of the end of the decompressed data PLUS 1. POKE177,n - Bank to which the compressed data is to be written. POKE253,n:POKE254,n - Low byte/high byte for the address to which the compressed data is to be written. As above, locations 253 and 254 or F% will report the end of the output buffer. DECODE RANGE OF MEMORY ---------------------- SYSADDR+15 This is the same as "Decompress Range of Memory," except that you must first POKE the desired values into memory then SYS directly to the M/L without parameters. POKE176,n - Bank containing compressed data. POKE251,n:POKE252,n - Low byte/high byte for the beginning address of the compressed data. POKE177,n - Bank to which the decompressed data is to be written. POKE253,n:POKE254,n - Low byte/high byte for the address to which the decompressed data is to be written. Although there may be times when "Pack Range of Memory" and "Decode Range of Memory" will be of use to the BASIC programmer they will be most valuable to the M/L programmer. STA, STX or STY values to the required registers as is convenient. Then JSR ADDR+12 or JSR ADDR+15 to accomplish compression or decompression. MEMORY MANAGEMENT ----------------- There is a great deal more RAM available in the C-128 than in the C-64, so memory management is seldom a problem. All you really need to know is: BASIC programs reside in BANK 0 anywhere from 7168 ($1C00) to 65279 ($FEFF). BASIC variables are written upward in BANK 1 from 1024 ($0400), and BASIC strings are written downward in BANK 1 from 65279 ($FEFF). This means that any available BANK 0 space following your BASIC program, and much of the area in the middle of BANK 1 is available to manipulate data. Just how much of BANK 1 remains available will be dependent upon how many variables, strings and arrays your program uses. PACK RLE TO DISK PROGRAM ------------------------ This BASIC program is an ultra Q&D utility. In fact, it is only two lines long. But, that's all that's necessary to compress a disk file to the same or another disk. To use this utility, type RUN"RLE DISK TO DISK" and press RETURN. The program will BLOAD 128/RLE, LIST line 100, print GOTO100, then STOP. Move the cursor up to line 100 and proceed as follows: Change the first half of the line by substituting the appropriate source filename and source drive. There should seldom if ever be a reason to alter the B0 or P12288. Continue in the second half of the line, following the colon (:) by substituting the appropriate destination filename, destination drive, and desired load address for the packed file. To avoid later confusion, it is best give the destination filename an RLE. prefix, however it is not mandatory. Enter P0 if you wish 128/RLE to respect the load address of the source file. When you are satisfied that line 100 is correct, make certain that the source disk and destination disk (if applicable) are in the drive(s), move the cursor down to GOTO100 and press RETURN. If you are compressing numerous files you can go back to line 100 and proceed as indicated above. Or you may prefer to write your own version and embellish this utility to suit your own needs. With 128/RLE's ability to process string and numeric variables as its parameters it would be a simple matter to incorporate keyboard input or an array to process multiple-file compression projects. As written, 128/RLE doesn't scratch an existing destination file so you must specify a different filename if that filename exists on the destination disk. As you contemplate uses for 128/RLE it may be helpful to know that although the C-64 and C-128 each need their own RLE program -- graphic, font and 40 column screen files created by either are fully interchangeable. Perhaps one of the most obvious uses for RLE packing is a graphics slide-show. But, whenever you find a need to conserve disk space 128/RLE is the answer. In the future, compression will become an even larger part of the computer industry, incorporated into the very chips of every computer. JEFF'S TUTORIAL ON PACKING SCREENS ---------------------------------- You'll find that this M/L won't pack screens as they are stored in memory. Screens and color memory are two separate chunks of memory. Screen memory is fine, but color memory, since it is part of hardware, and not RAM, is kind of tricky. This is because the M/L always reads and stores BENEATH the I/O image at $D000-$DFFF. Color memory is at $D800 for the 40- column screen. So the packing algorithm will read beneath the color nibbles to the RAM bytes in the same location, and the unpacker will always stash color beneath $D800, invisible to color. This becomes even more complicated in the 80 column mode where screen and color RAM must be written to indirectly. The way to pack screens is to first stash a screen anywhere with a toolbox, or your own M/L. Choose this place as your throwaway docking station for screens. You're going to immediately pack it and move it someplace else. Your stored screen will take up an 8-page range of memory. Next, pack the range of memory with 128/RLE. Locations 253 and 254 will report the end of the stored packed screen. There plus 1 is where you can store the next screen. Before you can re-display a packed screen, you must unpack it to a location where your screen switcher can then restore the screen. Since screens will be of variable length, you will have to come up with a workable management routine if you will be storing many, many screens. \\\\\ RETURN - Menu \\\\\